/**
 * @author SpringCat
 * @date 2025-03-24 17:16
 */
package org.ohara.mcs.core.storage;

// TODO 客户端获取配置后，增量更新本地缓存（Caffine）-> MapDB
// TODO 客户端向服务端的负载均衡算法

// TODO issue: MCC服务端启动时：从Redis拉取所有配置信息，覆盖自己的磁盘文件MapDB -> 更新本地缓存
// TODO issue: 持久化类型，默认是磁盘文件。可选DB或Redis（通过application.yml控制）

// 线性一致写，非线性一致读
// 🎯服务注册信息定期写入快照，启动时候加载这些快照 ✅
// Leader线性写入，Follower多节点读取 ✅
// 集群配置一致性 ✅
// leader广播给flower的时候，各个节点移除之前，先查一次，不存在再remove） ❌这个不做了，客户端和服务端直接通信配置信息就行了 唯一性 IP+Port+serviceName
// 🎯定时清理无心跳（心跳间隔超过60s）服务（交给Leader处理，并发问题(枷锁) ❌这个不做了，客户端和服务端直接通信配置信息就行了
// 🎯基于JRaft实现一个配置中心，客户端向服务端写入/读取配置时，如何获取服务端存活的node节点列表 ❓
// 客户端和服务端通信方式，如何建立长链接，监听服务端配置更新推送 ❓
// 客户端直接向MCC服务端配置查询时：从MCC服务端本地缓存读取
// MCC服务端配置更新时：找到自己的Leader -> leader更新（本地缓存、磁盘、redis） -> 广播给子节点（本地缓存、磁盘） -> 子节点推送给自己的客户端
// 配置变更推送的时候，需要先对配置内容进行MD5.如果前后版本内容没发生变化，就不会执行推送
